构建破折号264客户端:流媒体东部2013

本文是上述视频的文字记录, 拍摄于2013年流媒体东部会议, 其中Digital Primates的Jeff Tapper讨论了如何构建破折号264客户端以及其他与mpeg - dash相关的问题.

好吧. 受欢迎的,每个人都. 我是杰夫·塔珀. 这是一个关于建立一个破折号264播放器的会议. 简单介绍一下我:我是Digital Primates公司的高级顾问. 我们的重点是构建下一代客户端应用程序. 在过去十年左右的时间里，我有机会为许多收视率最高的直播节目开发视频应用程序. 在过去的17年里，我一直在构建互联网应用程序，在此期间，我有机会写了十几本书.

所以我们今天的议程是:我们将讨论HTTP流是关于什么的, 为什么它有趣?, 为什么我们会在意, 今天的HTTP流有哪些选择? 然后我们会具体讨论 破折号作为这些选项之一，我们会看到它为我们提供了什么. 我们来看看一个更窄的版本的破折号264，看看它是怎么回事. 然后我们会深入研究如何让它在浏览器中工作.

你们中有多少人认为自己是开发者? 优秀的. 你们熟悉的语言——你们大多数人都熟悉JavaScript? 好吧. 所以我们今天将花大部分时间在一个基于javascript的播放器上. 我们现在已经用几种不同的技术重新实现了它, 但是我们想要的JavaScript是最有趣的考虑到所有的炒作html5. 事实上，我们可以在浏览器中不需要任何插件就能完成这个工作，这很有趣, 至少对我来说是这样. 我猜你来这里也许对你来说也很有趣? 

好吧. 所以我们的挑战是:大多数人都同意HTTP流通常是一件好事. 正确的? 互联网在过去的15年或更长的时间里——到现在已经过去了20年——已经真正优化了通过HTTP传递内容. 多年来，我们已经有了许多不同的视频流协议，它们都不是基于http的, 而只是通过TCP有效地打开一个套接字并将数据向下推送. 有各种各样的问题，防火墙和其他类似的问题. 这样做也有一些好处. 我们有更低的延迟. 我们可以直接打开插座. 我们几乎可以立刻把碎片弄下来. 但我们无法利用互联网上的任何缓存服务器. 我们有各种各样的防火墙问题，所以HTTP流已经成为一个更有效的, 更优雅的选择.

视频正在主导互联网. 我们在互联网上有很多很多的视频. 我们正经历着指数级的增长——这并不奇怪——在移动端更是如此. HTTP自适应流媒体是当今互联网上流媒体内容的首选，其理念是我们取一个大文件, 我们将其分割成一系列小文件，并通过HTTP将其传递给最终客户端. 这样做有很多好处，也有很多缺点. 客户端需要更多的开销来将这些拼接成连贯的视频. 然而, 最终的好处是能够绕过我们所有的防火墙问题, 能够利用缓存服务器和当今互联网上存在的所有基础设施来支持HTTP传递，这远远超过了它的缺点.

在这个领域，我们有HLS(苹果的解决方案)，微软的Smooth Streaming, Adobe的HDS. 这三种方法都是有效的HTTP交付解决方案. 它们的内部工作方式有所不同，但最终它们都做同样的事情. 他们拍下一段视频，将其分割，然后提供单独的片段. 客户拿起碎片，然后把它们重新组装起来. 是有意义的?

好吧. 所以挑战在于, 正如我们所说, 这是一个非常有效的选择，但也存在问题, 当然, 使用HTTP流. 不同的设备支持不同的技术. 正确的? 苹果设备只支持HLS. 平滑流媒体目前可用于Xbox和silverlight, 我相信微软最近为Adobe的OSMF发布了一个插件, 开源媒体框架. 所以你可以在Adobe的技术中播放一些流媒体. 据我所知，HDS目前只支持Flash平台. 有没有人知道HDS是在非Flash平台上发布的? 但, 当然, Flash平台目前仍然是视频流媒体的主导平台. 世界上有很多HDS. 但目前还没有一种标准得到普遍支持. 因此，如果我们想要把视频传送到任何地方，我们就必须有几种不同的视频格式.

如果我们想把视频直接传送到浏览器，我们有什么选择? 唯一真正无处不在的是渐进式下载——将整个文件发送给他们——即使这样也有问题, 因为不同的浏览器支持不同的编解码器. 正确的? 有H.264，有WebM，有VP8，有VP9，以不同的方式支持不同的东西.

就实际流到HTTP浏览器而言, 只要在Mac OS或iOS中，Safari就支持HLS. Safari和Windows不支持HLS. 但有趣的是，最近有这些, 这些媒体源扩展和加密媒体扩展, mse和EMEs是这些东西的缩写, 它们是W3C频谱的一部分. 目前, Chrome浏览器支持这些媒体源扩展，这些扩展的作用是允许我们一次将一点点媒体数据交给HTML中的视频标签，从而可以控制HTTP流到基于浏览器的客户端.

这真的很有趣. 而HLS在Safari中是原生支持的, 作为开发者，我们无法控制流发生了什么. 我们只是告诉Safari，“嘿，这里有一个视频. “去播放它”，然后它就会做出关于视频的所有决定. 你在看什么质量的节目啊? You have no control; they decide. 什么是自适应比特率? 它们是内置逻辑. 如果你想控制信息流发生的事情，你真的做不到. 而对于媒体源扩展, 作为开发人员，当我们准备好交给API时，我们决定交给它哪些部分. 所以如果当我们传递一个内容时，如果我们意识到，“你知道吗? 这个打得不好. 我们掉了很多帧. 下载片段比播放片段要花更长的时间,“我可以切换到更低的比特率. 或者相反:也许我能决定, “嘿, 我有很多额外的空间:我想提供更高质量的比特率.“我们可以确定, 因为我们需要, 准确地将哪个段交给媒体缓冲区, 我们想下载哪些, 我们想玩哪些. 这就是为什么媒体源扩展对我来说如此有趣.

当然，现在的缺点是它们还没有得到普遍的支持. 它们目前在Chrome的发布版本中得到支持. 在Chrome的不同渠道中，你会发现不同程度的支持. 我们一直在与Chrome团队携手合作，以确保我们所做的工作在那里得到支持. 所以在Canary版本，也就是Chrome的夜间构建，我们有更好的支持. 在发布版本中，我们提供了一些支持和, 当然, 他们在努力打通渠道, 所以最终我们会得到所有这些的支持. 据我所知，其他浏览器制造商也将在不久的将来发布带有媒体源扩展的浏览器版本. 我不知道具体的时间安排. 关于这一点，我还有什么要说的吗? 这够近吗?? 我觉得已经很接近了.

这很有趣. 那么什么是MPEG-破折号呢? 有多少人知道什么是MPEG-破折号? 你们大多数人. 你们中有多少人参加了昨天关于破折号的小组讨论? 没我想的那么多. 好吧. 你们大多数人都知道, 对于那些不太了解的人来说, 破折号是基于HTTP的动态自适应流. 它是由ISO发布的一个国际开放标准. 它是由MPEG小组在2009年开始的，当时他们看到了HTTP流媒体技术中的所有分段. 他们召集了业内所有的主要参与者. 苹果、微软、谷歌、Adobe和许多其他公司聚在一起讨论“我们如何才能做得更好”?“这就是破折号. 从最简单的“这里, 只要播放这段视频“到非常高级的用例，包括AD插入和多语言支持以及您可能认为需要的任何其他功能. 说明书里有. 该规范大约有550页. 它不轻，夏日读书. 我不建议你带它去海滩，但它信息量很大. 和, 如我所说, 这个想法是试图为HTTP流的设备想出一个单一的标准.